A common mechanism for controlling an instrument is to have an embedded “real-time” controller that is responsible for tasks that must be completed on schedule; and a host computer that performs more complex sequencing, user interface, data processing, etc. The embedded system typically runs a real-time operating system or kernel, or no operating system at all, while the host computer runs an operating system such as MICROSOFT WINDOWS, MAC OS, LINUX, etc
The common paradigm for controlling such instruments is called “command-response”, e.g., see U.S. Pat. No. 5,185,866 and U.S. Patent Application Publication No. 1003/0215936, both of which are incorporated herein, in their entireties, by reference thereto. Using the command-response paradigm, the host computer sends a command to the embedded controller. The embedded controller, upon receiving the command, completes the command, and then responds to the host computer with a completion status message. If the host computer/user wants to read a parameter from the embedded system, a command is issued by the host computer to the embedded controller to request that parameter. The embedded controller, upon receiving the command, returns the requested parameter value in a return message sent to the host computer.
The command-response paradigm as described above, includes several
limitations that could be improved upon For example, each modification to the host computer system that requires a parameter to be read from the embedded controller generates a command that needs to be sent to the embedded controller. Each command sent from the host computer to the embedded controller perturbs the activity of the embedded controller in controlling the instrument to perform it scheduled tasks. Accordingly, this slows down operations.
If diagnostic tests are run which track parameters of the instrument being
controller, the load on the embedded controller/embedded system is quite different from the normal operational load. This can also slow operations.
Fault conditions are difficult to troubleshoot if insufficient state data has been sent from the embedded controller to the host computer and recorded on the host computer. “Back-channel” status reporting and recording mechanisms are often added for development and troubleshooting, but this increases complexity of the overall system and particularly of the embedded controller. Further, such mechanism are often ad-hoc, and as such are difficult to maintain and are difficult to utilize as test mechanisms at customer sites.
Control of concurrent activities by the embedded controller can become
quite complex using the command-response paradigm, as the host computer and embedded controller are required to keep track of which response belongs with each command.
Another drawback is that synchronization of state between the instrument hardware and the host computer software is complex and error prone.
Because of the limitations noted above, the programming of host
computer-embedded controller systems using the command-response paradigm tends to be parsimonious with transmission of parameters; or “back-channel” parameter reporting methods are added to enable the instrument to be monitored.
There is a continuing need for an improved control paradigm for controlling an instrument having an embedded controller by a host computer.